feat(BA-6659): materialize the Project scope's virtual scope on creation#12931
Draft
fregataa wants to merge 4 commits into
Draft
feat(BA-6659): materialize the Project scope's virtual scope on creation#12931fregataa wants to merge 4 commits into
fregataa wants to merge 4 commits into
Conversation
fregataa
added a commit
that referenced
this pull request
Jul 17, 2026
fregataa
force-pushed
the
feat/BA-6659-apply-virtual-scope-project
branch
from
July 21, 2026 04:41
dc66545 to
0aa0b48
Compare
fregataa
marked this pull request as ready for review
July 21, 2026 04:58
Comment on lines
+186
to
+195
| await self._role_manager.create_preset_roles(db_session, data.scope_id()) | ||
|
|
||
| return data | ||
| async with self._rbac_ops_provider.write_ops() as w: | ||
| await w.ensure_scope( | ||
| ScopeRef( | ||
| scope_type=VScopeType(RBACElementType.PROJECT.value), | ||
| scope_id=data.id, | ||
| ) | ||
| ) | ||
| return data |
Collaborator
There was a problem hiding this comment.
We'll adjust the timing for that part using ops as well.
fregataa
force-pushed
the
feat/BA-6659-apply-virtual-scope-project
branch
from
July 21, 2026 06:44
0aa0b48 to
fa84f07
Compare
fregataa
marked this pull request as draft
July 21, 2026 07:26
fregataa
force-pushed
the
feat/BA-6659-apply-virtual-scope-project
branch
from
July 22, 2026 06:22
fa84f07 to
bd73e00
Compare
Create a project's virtual scope through the ensure_scope RBAC op after the project row is created, so the project owns its child entities through the virtual-scope chain. The virtual-scope write runs in its own transaction via the injected RBAC ops provider. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Creating a scope now goes through one ops call that writes the row with its parent association, its virtual scope, its SYSTEM roles, and the roles its scope type's presets call for — so project creation is a single transaction again instead of splitting the virtual-scope write off on its own. - ScopeCreation becomes an ABC: an implementation names the row to insert and derives the scope from it, so the id stays database-generated. - Role provisioning is bulk: one insert for every role and one for every permission, whatever the number of scopes. - Scopes are addressed by ScopeRef throughout; the role/permission enums are reached only where the rows are written. - GroupCreatorSpec declares its integrity_error_checks, replacing the three pre-check SELECTs in GroupDBSource.create with the constraints themselves, which also closes the check-then-insert race. The system-role test now asserts the roles and permissions the database ends up with rather than the calls made to RoleManager. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…h RBAC ops Project purge and user add/remove now go through the RBAC ops provider so every membership change is recorded on the virtual-scope chain and scope deletion owns its whole contract. - remove_entity_members takes an EntityMembersRemoval mirroring the addition: members whose assign_role_on names a user also get every role at the scope revoked. - delete_scope/batch_delete_scopes accept RBAC entity purgers, so a scope delete cleans its permissions and scope associations along with the row and its virtual scope node. - GroupDBSource modify/assign/unassign/bind/unbind use add_entity_members and remove_entity_members via write_ops; purge_group deletes the group through delete_scope with the new ProjectPurgerSpec. - The db_source addresses projects and users by ProjectID/UserID, with the repository converting at its boundary. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…nel purge guard - remove_entity_members takes a scope and entity refs directly; membership removal no longer revokes the user's roles at the scope - replace the hand-written active-kernel pre-check in purge_group with a declarative conflict check on GroupKernelBatchPurgerSpec - drop the _project_scope/_user_entity_ref wrappers and construct ScopeRef/EntityRef at the call sites, typed with ProjectID/UserID - provision the virtual scope in the assign/unassign test fixtures now that membership writes resolve it Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
fregataa
force-pushed
the
feat/BA-6659-apply-virtual-scope-project
branch
from
July 23, 2026 02:50
bd73e00 to
02b1b5c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GroupDBSource.createnow materializes the project's virtual scope node (with its self-membership) in the same transaction as the project row and its RBAC roles, so a project becomes capable of owning child entities through the virtual-scope chain.RBACWriteOps.create_virtual_scope, a public entry point that creates the virtual scope node for a scope entity whose row is created through a separate path (here,RBACEntityCreator, which keeps the existing domain→project ownership association).Resolves BA-6659
🤖 Generated with Claude Code